Skunkware 5

home *** CD-ROM | disk | FTP | other *** search

/ Skunkware 5 / Skunkware 5.iso / man / cat.6 / xconq.6 < prev next >

Wrap

Text File | 1995-07-26 | 65.5 KB | 1,651 lines

LLLLIIIIBBBBEEEERRRRAAAATTTTIIIINNNNGGGG TTTTHHHHEEEE WWWWOOOORRRRLLLLDDDD ((((MMMMaaaaddddeeee SSSSiiiimmmmpppplllleeee)))) Stan Shebs Department of Computer Science University of Utah _A_B_S_T_R_A_C_T This is an in-depth document on version 5 of the _x_c_o_n_q family of programs. Version 5 is quite different from earlier versions; players familiar with those should read everything in here, espe- cially the section on important changes. All aspects of play are covered. Details on customi- zation may be found in a companion document. _W_a_r _i_s _a _m_a_t_t_e_r _o_f _v_i_t_a_l _i_m_p_o_r_t_a_n_c_e _t_o _t_h_e _S_t_a_t_e; _t_h_e _p_r_o_v_i_n_c_e _o_f _l_i_f_e _o_r _d_e_a_t_h; _t_h_e _r_o_a_d _t_o _s_u_r_v_i_v_a_l _o_r _r_u_i_n. _I_t _i_s _m_a_n_d_a_t_o_r_y _t_h_a_t _i_t _b_e _t_h_o_r_o_u_g_h_l_y _s_t_u_d_i_e_d. -- _S_U_N _T_Z_U (_c_a _4_0_0 _B_C) Welcome to _x_c_o_n_q, a chance for you to free the world from domination by evil empires. It is similar to previously distributed empire-building games, but with many more features. The same basic game is available with several different interfaces. _X_c_o_n_q is a fully X-based multi-player game, allowing almost any combination of human and machine players, and opening up remote X windows as necessary. There is also a restricted variant _c_c_o_n_q that needs the curses terminal package only, but allows only one human player. In the standard game, you start with one city and no knowledge of the world beyond your immediate vicinity. You must then explore, contact, and win wars against all the other players, who are trying to do exactly the same things to you! This is made harder by the limited information that the game supplies; except for the vicinity of your own pos- sessions (and for certain type of units), the entire view is out-of-date, and you won't see enemies until they're close by. The "standard game" is played on a small (usually 60x30 hexes) randomly generated map, against one machine player. Your first city will automatically start building your first June 22, 1995 - 2 - military unit (usually infantry). When it is ready, the starting city will be overwritten by a picture of the unit, which is itself surrounded by a box-shaped cursor (the "unit cursor"). The mouse (or standard Unix direction keys) may then be used to designate any location for that unit to move to. This movement may take several turns, or the unit may stop before it gets there, usually because it is adjacent to something unfriendly. To attack, just direct the unit to move into a hex that shows another unit, and see what hap- pens (flashes, and maybe a notice at the top of the screen). When you capture some kinds of units (usually cities), _x_c_o_n_q will ask you what sort of units you want that unit to pro- duce; '?' will display the possibilities. In general, '?' will always work. When typed during normal movement, you will get a series of help screens, including commands, news, and unit characteristics. (This info may be written into printable files if the interface doesn't have the screen space necessary.) The foregoing is sufficient to play - just jump in and go! After a few games, it should be clear what your units can and cannot do. The game will end automatically when your opponents are no longer capable of winning (either they have nothing left or they have given up). The following sections contain many boring details, and should be referred to for answers to questions. _D_E_F_I_N_I_T_I_O_N_S _O_F _T_E_R_M_S An xconq game involves several _s_i_d_e_s, each of which has a human or machine player associated with it. Sides may be enemies, allies, or neutral with respect to each other, often start out in a hexagonal _c_o_u_n_t_r_y. A side owns a number of _u_n_i_t_s, which includes the cities and the armed forces of that side. Units may also be _n_e_u_t_r_a_l, and belong to no side (this is different from being on a neutral side). Units may be inside other units, in which case the one inside is in _o_c_c_u_p_a_n_t, and the other is a _t_r_a_n_s_p_o_r_t (even if it can't move). Units always have _o_r_d_e_r_s that they follow, even when they appear to be under manual control. There are also _s_t_a_n_d_i_n_g _o_r_d_e_r_s that get passed to occupants automati- cally. The game is divided into a number of _t_u_r_n_s, during which each side gets to move some or all of its units. All the action happens over a _m_a_p of a real or imaginary world that is divided into hexagonal shapes usually called _h_e_x_e_s. Each hex has a _t_e_r_r_a_i_n assumed to cover the entire hex. In some games, hexes also have a _p_o_p_u_l_a_c_e belonging to some side. Terrain on the map can produce _r_e_s_o_u_r_c_e_s, which are natural items ranging from water and food to gold and weapons; resources being carried by a unit are also called _s_u_p_p_l_i_e_s. _S_c_e_n_a_r_i_o_s are predefined games that set up maps, sides, units, and _w_i_n/_l_o_s_e _c_o_n_d_i_t_i_o_n_s, which define the cir- cumstances under which one or more sides win or lose in the June 22, 1995 - 3 - scenario. The numbers and kinds of units, resources, and terrain are not built in; they are defined by a historical (or ahistori- cal!) _p_e_r_i_o_d. This means that the following sections will be somewhat vague on specific units and behaviors, since the information applies to times ranging from Ancient Greece to Star Wars. Later sections will describe some of the periods that have been developed so far; in addition, complete online help is available on the period in effect. _T_H_E _W_O_R_L_D _G_e_o_g_r_a_p_h_y _d_e_f_i_n_e_s _t_h_e _b_a_c_k_g_r_o_u_n_d _t_o _c_o_n_f_l_i_c_t. _G_o_l_d _m_i_n_e_s _a_r_e _u_s_u_a_l_l_y _i_n _t_h_e _m_o_u_n_t_a_i_n_s, _f_a_r _f_r_o_m _t_h_e _s_e_a. _I_s_l_a_n_d_s _t_e_n_d _t_o _b_e _l_e_f_t _a_l_o_n_e, _u_n_l_e_s_s _t_h_e_y _a_r_e _o_n _a _d_i_r_e_c_t _p_a_t_h _s_o_m_e_w_h_e_r_e _e_l_s_e. _A _s_e_a_c_o_a_s_t _t_o_w_n _c_a_n _b_e _s_t_r_a_t_e_g_i_c_a_l_l_y _u_s_e_l_e_s_s _i_f _i_t_s _a_p_p_r_o_a_c_h _i_s _t_h_r_o_u_g_h _s_h_a_l_l_o_w _w_a_t_e_r. _A_t_t_e_n_t_i_o_n _t_o _t_e_r_r_a_i_n _a_n_d _i_t_s _e_f_f_e_c_t _o_n _o_n_e'_s _u_n_i_t_s _c_a_n _m_a_k_e _t_h_e _d_i_f_f_e_r_e_n_c_e _b_e_t_w_e_e_n _w_i_n_n_i_n_g _a_n_d _l_o_s_i_n_g. The world map on which you play is a cylinder of variable height and diameter. Although it is always displayed as a rectangle, you can actually circumnavigate the world. The most northerly and southerly rows of hexes are out of bounds. Sizes can range from 20x20 "quicky" maps to the Earth at 1 degree resolution between 60 north and 60 south - no less than 360 by 120 hexes! When starting up, you have the choice of several maps of real areas, depending on the period, or by default you get a randomly-generated 60x30 map. You can get other sizes from about 10x10 up to whatever your machine's memory can hold, by using the ----MMMM option on the command line. The ----mmmm command line option loads a named map, and the ----xxxx option may also offer a menus of maps to use. Predefined maps usually have their own documentation, which is displayed on one of the help screens. Each individual hex of the world contains one kind of ter- rain, which is assumed to more-or-less cover the entire hex. The exact set of terrains depends on the historical period; the set below is from the standard period, and is actually shared by many periods. Monochrome _x_c_o_n_q uses icons for each type of terrain, which cannot possibly be described verbally, so use the help commands to decipher them. Sea (dark blue) is assumed to be deep enough for any ship. Armies can't walk on water. Shallows (light blue or cyan) include shoals, reefs, rivers, and any other sort of shallow water. They res- trict movement of ships and may entirely prevent pas- sage of the largest ships. June 22, 1995 - 4 - Plains (light green) are generally flat and hospitable areas. They usually offer no impediments to movement. Forest (dark green) is dense forest or jungle, and may hinder movement for some kinds of units. Swamps (gray) are half water and half land, and impass- able to almost everybody. Desert (yellow) ranges from Saharan sands to Sonoran cacti. It is always inhospitable but fast to move through - think of armor in North Africa. Mountains (brown) are relatively barren and at higher elevation, thus are also inhospitable to troops. Ice (white) is deep snow, ice, and glaciers. Only spe- cially equipped ground units can pass over it, although most aircraft can fly over. Vacuum (black) is outer space, included for the purpose of doing futuristic periods. Each hex is adjacent to six others, and there is no special border to cross. By default, hexes represent areas about 100 km on a side, although many maps have larger or smaller scales. Randomly generated maps vary in their "roughness", and in the percentages of each kind of terrain. These properties also depend on the period, and it is worthwhile to have a general idea of the values. Percentage coverage is simple (for instance, the earth is 70% covered by water), but roughness is more subtle; essentially the "jagginess" of the terrain. Very rough terrain has lots of sharp peaks and small islands, while smooth terrain has large flat con- tinents. SIDES _P_o_l_i_t_i_c_s _p_r_o_v_i_d_e_s _t_h_e _c_o_n_t_e_x_t _f_o_r _w_a_r; _t_h_e _w_a_r _b_e_i_n_g _a _r_e_s_u_l_t _o_f _f_a_i_l_e_d _p_o_l_i_c_y. _T_h_e _l_e_a_d_e_r _o_f _a _c_o_u_n_t_r_y _i_s _f_a_c_e_d _w_i_t_h _t_h_e _p_r_o_b_l_e_m _o_f _a_c_h_i_e_v_i_n_g _c_e_r_t_a_i_n _g_o_a_l_s, _e_i_t_h_e_r _e_x_t_e_r_n_a_l_l_y- _o_r _s_e_l_f-_i_m_p_o_s_e_d. _D_i_p_l_o_m_a_c_y _c_a_n _s_o_m_e_t_i_m_e_s _a_c_c_o_m_- _p_l_i_s_h _t_h_e _d_e_s_i_r_e_d _o_u_t_c_o_m_e, _a_n_d _i_s _m_u_c_h _c_h_e_a_p_e_r _t_o _b_o_o_t. _W_h_e_n _i_t _f_a_i_l_s, _o_n_e _c_o_u_n_t_r_y _o_r _a_n_o_t_h_e_r _d_e_c_l_a_r_e_s _w_a_r, _a_n_d _a_n_y _a_l_l_i_a_n_c_e_s _i_m_m_e_d_i_a_t_e_l_y _b_r_o_a_d_e_n _i_t_s _s_c_o_p_e. _D_e_c_l_a_r_i_n_g _p_e_a_c_e _a_g_a_i_n _i_s _m_u_c_h _m_o_r_e _d_i_f_f_i_c_u_l_t... Sides in the game can be allies or enemies in various combi- nations. Any two sides can form a formal alliance; human players do it by sending the message "alliance" to each other using the message command (see below). Machine players are "aware" of their relative incompetence, and will June 22, 1995 - 5 - usually ally with each other (except in the case of a machine player attached to a display, so as to facilitate debugging). Players may become neutral or declare war by sending the messages "neutral" and "war" to another side. Scenarios may sometimes set up particular patterns of alli- ances, although there is nothing to prevent the players from changing them around during the game. If all the sides left in a game are allied, then it automatically ends. Some displays distinguish alignments by using the same colors for allies as for yourself, while painting neutrals and enemies in distinctive colors. For others, you just have to remember who is on whose side. Names of sides come from a scenario or are randomly gen- erated from a list of names, depending on period. If the period doesn't define any names for sides, then the list will be 100+ contemporary names (including Botswanans and Peruvians). Players may also rename themselves, using a command (see below). Since it is usually hard to remember which player has which name, many mentions of sides include the display that the side is using (or nothing if a machine player), or sometimes the number of the side (especially for input). When a side loses, for whatever reason, units are either destroyed or made neutral (depending on unit and period). In the standard period, infantry is destroyed, while cities become neutral (thus easy pickings for the remaining players who get to them the quickest). Informal alliances frequently happen in games involving more than two people, so I have a few words of advice. First, an alliance between two of the players is almost certain in a three-person game, and inevitably results in the "odd man out" being quickly defeated. In four-person games, the alliances should be decided after looking at the map via "- v", so that one pair is not hopelessly separated. Five or more players is going to be a free-for-all of formal and informal alliances. Some scenarios are designed with a par- ticular number of players in mind; hopefully they will also have some natural balance. _U_N_I_T_S _W_a_r _i_s _b_a_s_e_d _o_n _t_h_e _a_p_p_l_i_c_a_t_i_o_n _o_f _f_o_r_c_e _t_o _t_h_e _o_t_h_e_r _s_i_d_e, _u_s_i_n_g _w_h_a_t_e_v_e_r _i_s _a_v_a_i_l_a_b_l_e; _f_r_o_m _s_p_e_a_r_s _a_n_d _a_r_r_o_w_s _t_o _t_h_e _h_i_g_h-_t_e_c_h _e_q_u_i_p_m_e_n_t _a_v_a_i_l_a_b_l_e _a_s _a _s_i_g_n_i_f_i_c_a_n_t _f_r_a_c_t_i_o_n _o_f _a _n_a_t_i_o_n'_s _G_N_P. Units can be almost anything: armies, balloons, triremes, cavalry, battleships, bridges, headquarters, cities. Units move around, attack other units, produce resources, and build more units, among other things. Individual units June 22, 1995 - 6 - occupy entire hexes, and no other unit can enter that hex unless it can occupy or be occupied by the unit already there. Only some kinds of units can build other units, at a rate depending on the period, the unit being built, and the unit doing the building. The first unit that is produced takes somewhat longer, and the very first unit built by a side can take even longer (research and development time), but then succeeding units come out at a constant rate. There is no memory about production, so switching to a different type then switching back still incurs the extra startup time. Most units that do building will do it all the time, and only stop when explicitly directed to (such as cities), while others need to be directed to build, and cannot move while doing so (such as engineers building a base). Once created, a unit moves according to its orders, and sub- ject to various constraints - armies can't swim, ships can't walk, etc. Units can sometimes be disbanded with a command (depending on the period), by losing them in battle, by run- ning out of supplies, by being taken prisoner when a unit is captured, or by garrisoning a captured unit. Every unit starts out with a number of _h_i_t _p_o_i_n_t_s represent- ing its strength, and possibly supplies of food, fuel etc that it carries around. Supplies are used up by movement, combat, and by just existing, and are created by production on certain terrain types, or by transference from some other unit. There is only one situation under which several units can be in the same hex at once; if one is a transport of some sort and the others are its passengers or occupants. The notion of "transport" and "occupant" is general, and covers fighters on carriers, ships in port, bombs in bombers, and troops being led by a general. Occupants board by moving into the hex occupied by the transport, but will refuse to go if the transport is full or can't carry that type of unit. Getting on board takes a number of moves of that unit; if there are any left, it may move off or take some other action. Transports can also move over a occupant to take it on, but only if the transport can move on the ter- rain that the occupant is on. Occupants always move with the transport (that's what transporting is all about!), but may leave at any time if possible, either onto a valid ter- rain or onto another transport. To debark, just move the unit off (the cursor indicates that the occupant and not the transport is to be moved). Usually, you will want to put the occupant on sentry duty while moving the transport, and so must wake the occupants up before they can be moved again. June 22, 1995 - 7 - _T_H_E _G_A_M_E Games may be predefined scenarios, which define the map, sides, and units, or they may be randomly generated. If randomly generated, depending on the period, you start with either a country-full of units or just one, which may or may not have its production defined already. If you start with one, the period may also define some neutral units in your country, which should be captured as quickly as possible. Sometimes the map will be too small or have the wrong ter- rain, and then _x_c_o_n_q will fail at placement and exit instantly. There is not much you can do at that point except to try again or relax the constraints, perhaps by reducing the number of sides or increasing the map size. (This can also be fixed by altering the period - see the customization document for details.) Since there is a lot of randomness in placement, second tries are frequently suc- cessful, although tenth tries usually indicate a real prob- lem. A turn consists of several phases, although only one actu- ally involves player interaction: Spy PhaseLeakage of information from one side to another. Disaster PhaseRevolts, surrenders, attrition, and accidents. Build PhaseConstruction of new units and repair of damaged ones. Supply PhaseProduction and distribution of resources. Movement PhaseAutomatic and manual movement of all units. Consumption PhaseDetails relating to supply usage during movement. During the movement phase, the program iterates through all units, prompting each side to give orders to any unit that is awake or becomes awake during the course of its move. One consequence is that you will not have a chance to change orders, look around, or do anything else if no unit produces a unit and no units wake up. This speeds playing but can be annoying if you get overrun and lose without ever getting a chance to respond (but do you deserve anything else for pur- suing a "hands-off" management strategy?). Sides that lose are automatically cut out of the game. Since one additional iteration is needed to verify that somebody lost, the final winner will have to go through an entire turn before the game will exit (doing the sentry command on everything is easy and quick). The game ends when the win/lose conditions have been met; June 22, 1995 - 8 - these vary from scenario to scenario. For a randomly- generated game, the end comes when no mutual enemies are left, whether by elimination or by peace. Usually this means that only one side is left alive, but multiple machine players (not associated with displays - the usual case) are always allied, and thus may win as a group. This also means that a single member of the alliance will not resign until the position of the whole alliance is hopeless; after all, the WWII Allies included several brigades of Polish troops after Poland was overrun. The last player must type a key to close down the windows (this is so that they will stay up for everybody to look at). When the game closes down, the winners (if any) will be listed. If the STATISTICS option has been set by the installer, _x_c_o_n_q will write a file "stats.xconq" into the current directory. This file summarizes some crucial statistics concerning combat performance, losses, and other miscellany. It is quite useful for rationalizing your humi- liating defeat! _D_I_S_A_S_T_E_R _P_H_A_S_E _W_a_r _i_s _i_n_h_e_r_e_n_t_l_y _r_a_n_d_o_m. _B_o_t_h _m_i_l_i_t_a_r_y _a_n_d _c_i_v_i_l_i_a_n _u_n_i_t_s _d_e_s_e_r_t, _g_e_t _d_i_s_e_a_s_e_s, _h_a_v_e _a_c_c_i_d_e_n_t_s, _d_e_f_e_c_t, _a_n_d _s_u_r_r_e_n_d_e_r _w_i_t_h_o_u_t _a _s_t_r_u_g_g_l_e. _T_h_e_s_e _e_f_f_e_c_t_s _c_a_n_n_o_t _b_e _e_l_i_m_- _i_n_a_t_e_d _c_o_m_p_l_e_t_e_l_y, _b_u_t _c_a_n _b_e _r_e_d_u_c_e_d _b_y _k_e_e_p_i_n_g _o_n_e'_s _f_o_r_c_e_s _o_u_t _o_f _h_a_z_a_r_d_o_u_s _s_i_t_u_a_t_i_o_n_s _a_n_d _b_y _k_e_e_p_i_n_g _m_o_r_a_l_e _u_p. Three types of disasters can befall a unit during the disas- ter phase: revolt/surrender, attrition, and accidents. Revolts and surrenders are really the same sorts of occurrence; a unit changes sides spontaneously, perhaps to neutrality, perhaps to the side of a nearby enemy unit. During every disaster phase, each unit makes a revolt check. The revolt chance is a hundredth percentage. When a unit revolts, it changes to its original side (whatever the unit started out as - i.e. your initial units will never revolt). Occupants will either change over or be killed. Any con- struction will be cancelled, unless the scenario is one in which construction changes are not allowed. Surrender only occurs if a unit is capable of capture is present. The capturing unit does not move. Occupants of the surrendering unit also change over or die. Chance of surrender is increased by low unit morale. The chance of surrender can be greatly increased (depending on period) by surrounding the unit completely. This includes naval units for any sea hexes. One of the sur- rounding units must be capable (even if only a small chance) of capturing the unit by direct attack. The siege is only in effect in those turns where the unit is completely June 22, 1995 - 9 - surrounded. When the unit surrenders, one of the "capture- capable" units will be randomly picked to accept the surrender, and things happen as for a direct assault (described below). Note that if several sides are surround- ing the same unit, the selection is still random from among those sides, as long as the side is an enemy. Attrition is a "slow death" process applicable primarily to multi-hp units. It takes away some number of hit points each time it occurs, and kills units only if they have no points left. Attrition is also specified in hundredths of a percent, and depends on unit type and terrain type. Morale drops by 1 when attrition occurs. A message will be displayed as well. Finally, there is a chance for an accident to destroy a unit instantly and totally. Like attrition, this depends on both unit and terrain type, and is measured in hundredths of a percent. If the accident occurs, the unit is killed along with all occupants. A message will be displayed. _B_U_I_L_D _P_H_A_S_E _S_u_s_t_a_i_n_e_d _e_f_f_o_r_t_s _i_n _a _w_a_r _d_e_p_e_n_d _v_i_t_a_l_l_y _o_n _t_h_e _r_e_p_l_a_c_e_m_e_n_t _a_n_d _r_e_p_a_i_r _o_f _f_o_r_c_e_s _d_e_s_t_r_o_y_e_d _o_r _d_a_m_a_g_e_d _i_n _c_o_m_b_a_t. _I_n _t_o_t_a_l _w_a_r, _t_h_e _p_r_o_d_u_c_t_i_o_n _b_a_s_e _c_o_n_s_t_i_t_u_t_e_s _a _c_h_i_e_f _s_t_r_a_t_e_g_i_c _t_a_r_g_e_t, _t_o _b_e _i_s_o_l_a_t_e_d _o_r _d_e_s_t_r_o_y_e_d _i_f _p_o_s_- _s_i_b_l_e. _R_e_p_a_i_r _o_f _u_n_i_t_s _i_s _a_l_s_o _s_i_g_n_i_f_i_c_a_n_t _s_i_n_c_e _a _b_a_t_t_l_e _m_a_y _r_e_s_u_l_t _o_n_l_y _i_n _d_a_m_a_g_e, _b_u_t _b_e _s_u_c_c_e_s_s_f_u_l _n_e_v_e_r_t_h_e_l_e_s_s _i_f _u_n_i_t_s _m_u_s_t _r_e_t_i_r_e (_a_s _a _c_h_e_a_p_e_r _a_l_t_e_r_n_a_t_i_v_e _t_o _n_e_w _p_r_o_d_u_c_- _t_i_o_n). _H_i_s_t_o_r_i_c_a_l_l_y, _b_a_t_t_l_e _d_a_m_a_g_e _h_a_s _r_e_s_u_l_t_e_d _i_n _t_h_e _t_e_r_- _m_i_n_a_t_i_o_n _o_f _a_n _e_n_t_i_r_e _c_a_m_p_a_i_g_n. During the build phase, units construct new units and repair damaged occupants (or themselves). Construction is straightforward; the schedule is decremented once/turn. When it has counted down to zero, the unit is created, and placed either as an occupant of the builder, or the builder is made to occupy the new unit. If neither alternative works (perhaps because the builder is full already), then completion is postponed, and attempted on the next turn. This will be repeated indefinitely. If the new unit cannot be placed at all, it is thrown away. If the period specifies that the builder is to guard the new unit, then the builder will be assigned to garrison the new unit, and is destroyed. Repair happens automatically if the damaged unit contains or is contained by another unit capable of repairing, or if the unit can repair itself. The repair rate is depends on both the repairer and repairee, and can happen no faster than one hp/turn. June 22, 1995 - 10 - _S_U_P_P_L_Y _P_H_A_S_E _T_h_e _A_l_l_i_e_s _f_l_o_a_t_e_d _t_o _v_i_c_t_o_r_y _o_n _a _s_e_a _o_f _o_i_l. -- _L_O_R_D _C_U_R_Z_O_N. Resources themselves are basically inanimate material that come in varying amounts and are governed by conservation laws. They can be produced, moved around, and consumed dur- ing various activities. Resources originate either as sup- plies carried by units at the outset, or more typically, through production by units. Production rate depends on unit, resource, and terrain types, and is unaffected by side changes, combat, or anything else. Produced resources go into the producing unit's storage. Excess production is discarded, unless it can be unloaded into the producer's occupying units, or distributed to nearby units via _s_u_p_p_l_y _l_i_n_e_s. Supply lines automatically exist between units that are close enough (as decreed by the period), and there is no need for explicit manipulation. Units consume their supplies, both in the course of existence, and by motion/combat. The rate depends on period and unit type; it consists of an overhead consumed each turn without fail, and consumption for each hex of movement. The total is a max, not a sum, since units with a constant con- sumption rate are not likely to need additional supplies to move (consider foot soldiers who eat as much sitting around as they do walking). Supplies may also be consumed for pro- duction and repair, again depending on period and unit types, but this consumption happens during the build phase. Consumption is not affected by the situation of the consum- ing unit; armies in troop transports eat just as much as when in the field. Supply line length depends on the period and the units on both ends, but is not affected by the intervening terrain. Supply redistribution is managed by logistics experts, who are ignorant of the war effort and seek only to even every- thing out. The redistribution method is rather adhoc; units try to get rid of all their excess supply, and try to take up supply from other units within supply range. Each direc- tion is controlled independently, so for instance airplanes can get automatically refueled from a nearby city, but not from each other. No unit will transfer all of its supply via supply lines. Normally units in the same hex can exchange supplies, but some periods can disable this behavior, so that explicit transfer using the give and take commands is always necessary. _M_O_V_E_M_E_N_T _A_N_D _C_O_M_B_A_T The movement phase is the one in which all the action hap- pens. At its outset, the phase computes the number of moves June 22, 1995 - 11 - available to each unit. This value is essentially the max- imum of the unit's moves on each type of terrain. The move- ment phase continues until all these moves have been expended in some way or another. Some periods may define a small chance of random movement, in which the unit moving actually goes in some other direc- tion than that intended. This is a potentially dangerous occurrence, since the unit will be destroyed if the hex is impassable or contains another unit (whether or not the other unit can take the moving one as an occupant). All combat occurs during the movement phase. Battles happen when one unit attempts to move onto a hex occupied by an unfriendly unit. In most periods, each unit attacks the other equally well, but if "counterattack" is not enabled, then the defender just has to sit and take the punishment. The outcome is determined independently for each unit, based on a probability table; this means that both draws and mutual damage/destruction are possible. The odds are the same whether a unit is attacking or being attacked. Ammuni- tion may be expended by each unit in each combat - if the ammo is gone, then the attacker will not attack and the defender cannot defend itself. The results are announced both by a message and by some flashes on the screen (the size of the flash corresponds to damage seriousness). Dam- age is assessed using hit points, and if the hit points are zero, the unit is destroyed, along with any occupants. Typ- ically armies have only one hit point each, so they are des- troyed if hit. Units with multiple hit points may be _c_r_i_p_- _p_l_e_d if their hit points drop below a period-specified level. Crippled units move more slowly (in proportion to their damage), have reduced transport volume, cannot repair anything, and do not make progress on any construction. The final outcome of combat depends on whether the defender was destroyed. If so, the attacker will move into the defender's position (if possible), otherwise no movement will happen. If a unit is hit sufficiently hard, that is considered a "nuke" and you get more spectacular visual effects, plus the hex is converted into desert or something else desolate. Some units are capable of capturing other units, with a pro- bability depending on the types of both units involved. If the capture attempt is successful, the capturer will move into the hex if possible, either as occupant or transport. In some periods, the capturer may be all or partially dis- banded, to serve as guards. The regular attack as described above always happens first. June 22, 1995 - 12 - _O_R_D_E_R_S _A _p_e_r_e_n_n_i_a_l _f_e_a_t_u_r_e _o_f _t_h_e _h_i_g_h_e_s_t _l_e_v_e_l _o_f _c_o_m_m_a_n_d _i_s _i_t_s _i_n_h_e_r_e_n_t _c_o_m_p_l_e_x_i_t_y. _A_l_t_h_o_u_g_h _t_h_e _u_s_e _o_f _s_u_b_o_r_d_i_n_a_t_e_s _r_e_d_u_c_e_s _t_h_e _b_e_w_i_d_e_r_m_e_n_t _s_o_m_e_w_h_a_t, _t_h_e _c_o_m_m_a_n_d_e_r-_i_n-_c_h_i_e_f _m_u_s_t _s_t_i_l_l _k_e_e_p _i_n _m_i_n_d _h_u_n_d_r_e_d_s _o_f _a_p_p_a_r_e_n_t_l_y _u_n_r_e_l_a_t_e_d _f_a_c_t_s; _t_h_e _s_t_a_t_e _o_f _t_h_e _w_e_a_t_h_e_r, _t_h_e _p_a_s_t _p_e_r_f_o_r_m_a_n_c_e _o_f _u_n_i_t_s, _t_h_e _c_u_r_r_e_n_t _g_o_a_l_s _o_f _t_h_e _w_a_r, _a_n_d _m_a_n_y _o_t_h_e_r _t_h_i_n_g_s. _I_t _i_s _v_e_r_y _i_m_p_o_r_t_a_n_t _t_h_a_t _l_o_w_e_r-_l_e_v_e_l _u_n_i_t_s _b_e _a_b_l_e _t_o _o_p_e_r_a_t_e _o_n _t_h_e_i_r _o_w_n _a_s _m_u_c_h _a_s _p_o_s_s_i_b_l_e. Although units have been said to "move", in actuality they follow orders, some kinds of which specify movement. When you are moving a unit hex-by-hex, it is following the order "Awake", which just means that every turn it asks what to do next. There are many kinds of orders. Some, such as move- ment in a given direction, or to a given place, take parame- ters, but all take a repetition, which tells for how many turns the unit will carry out the order. (For some orders, the repetition is not particularly meaningful, and is ignored.) Repetition is always specified as a prefix numeric argument to commands. Orders that a unit can do include: Awake ask for a movement or other command. Sentry sit at the present location as long as the repeti- tion says. MoveDir move in the given direction. MoveTo try to move to the given location. FollowCoastattempt to follow a coastline. FollowLeadermove towards another given unit (which must be one of your own). Patrol go back and forth between two points. Most movement commands just give these orders to the unit currently being prompted about. In addition, a unit may be given "standing orders", which will be passed to any unit of a particular type entering or produced in that unit. This is useful for a variety of purposes, such as staging fighter planes up to the front lines or sending ships out on stan- dard patrols. _T_H_E _D_I_S_P_L_A_Y _A_l_l _w_a_r_f_a_r_e _i_s _b_a_s_e_d _o_n _d_e_c_e_p_t_i_o_n. -- _S_U_N _T_Z_U When a game is started up, it opens a number of windows, of June 22, 1995 - 13 - which the most important is the area map (which therefore gets the largest window). Above the area map are several windows for status and notifications, and next to those is a turn counter and a list of all sides in the game. The middle right side has a list of all unit types, used for statistics display, while the lower right-hand corner has a map of the world (if the display is sufficiently large). All of the _x_c_o_n_q windows are actually subwindows of a main window with a patterned background you can see here and there. You can iconify and move the main window, and the subwindows will keep their relative positions. The largest of these is the map, which is a (typically) 30x30 section of the world in full detail. The view is scrolled around as necessary (remember that the world is cylindrical). To the right and down, you see a map of the whole world. This view is like the close-in map, but units and units are rendered as solid blobs, since the world is too large to permit any detail. To assist in matching up the two dif- ferent views, the world map includes an outline box indicat- ing the position of the close-in view. Three text displays are stacked at the top of the screen. The uppermost is about ten lines of notices about various occurrences, each prefixed by the number of the turn in which it was issued. The display scrolls. The next four lines are an information window that summarizes the status of the unit or unit at the current cursor position. It can display info about enemy things also, but of course the amount of information is less. Finally there is a one-line prompt window just above the map, in which all questions and prompts appear. The list of sides playing appears in the upper right corner. Sides that have already lost appear with a line through them, while the currently moving side has a "*" next to it. Your own side name is highlighted or inverted. The name of the side, its host (if any), and the number of that side are shown. On color displays, the color of the number indicates the alignment of that side. The X interface draws the area map as a number of hexagonal shapes with icons for units superimposed. Unknown territory is black. Your own possessions appear in black, neutral units in gray, and all enemies in red. If there is more than one enemy side, they are distinguished by the number of their side in the upper right corner of the icon. Not all enemy units will be visible; the chance of seeing one may be very low, or depend on viewing with the right type of unit. Monochrome screens display enemies and neutrals as inverted from your own appearance, and all enemy units/units have numbers, to distinguish them from the neutral units. June 22, 1995 - 14 - The curses interface displays each hex as two characters side-by-side. Terrain is a character representing the ter- rain, as are units. The second character in a hex is either the side number of an enemy, or an apostrophe for neutrals. As mentioned previously, the view is a record of what has already been seen, but is not updated except in the immedi- ate vicinity of your own units and units. In multi-human games, all screens will be kept up-to-date simultaneously, so that persons waiting for their turns can see enemy units moving around, units change hands, and so forth. _I_N_P_U_T Input may be supplied both from the mouse and the keyboard. Moving the mouse cursor to a screen position and clicking either button has the effect of issuing MoveTo orders to the current unit, which will be carried out until successful. There are two exceptions. The first is that if the mouse is on the unit itself, the unit sits where it is until the next turn (same as the ' ' command below). If the desired new position is adjacent, the unit will unconditionally move there - this is useful for attacking enemies. At present, there is no special meaning attached to particular mouse buttons. As an alternative to using the mouse, the standard direc- tions (h = West, l = East, y = NW, u = NE, b = SW, n = SE) can be used to specify movement. Uppercase versions of these makes the unit move forever in that direction. Letter directions are really only of use when the mouse fails, or for diehard Unix game players for whom the direction keys have been permanently wired in the brain! Note that in a hexagonal system, 'j' and 'k' are not meaningful. Any command may be prefixed by a single numeric argument (which may be positive or negative). Not all commands will use this number, while others need a number to know how often to repeat an order, or perhaps for some other reason. The "current unit" is the one being prompted about, while the "main unit" is the one occupying the hex itself (as opposed to its occupants). Commands to give units orders typically default to a repeti- tion of 100 turns (In some cases, this is meaningless, as in moving to a place): s Sentry; the current unit "goes to sleep", only wakes up by explicit command or when an enemy pops into view (the enemy unit won't necessarily be adjacent, if the unit on sentry duty can see far-off hexes). June 22, 1995 - 15 - w Wake up; the unit's orders will be erased (whatever they were) and it will ask about its next order (not always immediately). This command interprets an argu- ment as a radius for the effect of waking up; for instance, the default of 0 means to wake only the unit itself, 1 means to wake up adjacent units as well, 15 will wake up a screenful of units, and 999 will usu- ally wake all units. W Wake all; both the unit and all its occupants will be woken up, as well as all of their occupants, recur- sively. The command is otherwise identical to 'w'. Space Sit; unit goes on sentry duty for exactly one turn, and will ask for a move in the next turn. Useful for waiting one or two turns. r Return; unit returns to nearest transport by shortest route. It will not return to transports with no room or no supplies. Most useful for aircraft, but works with any unit. m Move to a position; this is equivalent to mouse click- ing, but can be used with mouse-less interfaces or to move further than one screen width. You will be prompted to do movement commands (either mouse or key- board), then can use the space bar to designate the final destination. f Follow leader; follow another unit. The program will ask you to designate a unit to be followed, which must be one of your own. The interaction is identical with that for 'm'. Each turn the unit either attempts to move towards its given leader, and sits if it is within a couple hexes of the leader. Units will not follow themselves. F Follow coast; follow a coast line. This can be applied to any unit, although the unit will immedi- ately wake up again if it is not next to some sort of terrain that it cannot move into. The command will prompt for a standard direction to decide how to start, then a contour-following algorithm will con- tinually try to keep the unit adjacent to impassable terrain (thus armor might use this command to go around a mountain range or forest). Because the ter- rain is in discrete hexes, it is possible for the unit to get confused, but that's life. Z Patrol; set the current unit to go back and forth between two points. One point is the unit's current position, and the other will be prompted for. The roundtrip will be repeated for the number of times designated by the command's argument. June 22, 1995 - 16 - Commands for modes. There are only two modes defined at present: move mode (the default) and survey mode. Most com- mands work the same in both modes. z Survey mode; toggle into/out of survey mode. In sur- vey mode, movement pushes a cursor and allows you to look at things. The other commands are still avail- able; for instance, you can give a unit new orders or to set unit production. Commands for general manipulation of units: d Delay move; unit's movement is delayed until all your other units have been moved, then it will be prompted for again. Useful in crowded situations. Delay can be used on any number of units any number of times during a turn. P Set unit production; will ask for a type of unit (if a choice possible) and then schedule construction for a unit of that type. Any partial production will be discarded. I Idle; cancel production for the given unit and leave it idle for a while Default is 100 turns, argument to command overrides. C Call unit by name; prompts for a string by which current unit will be referred to. If string is empty, unit name will be removed. If this command is done when the cursor is on an empty hex, the string will become the new name of the whole side instead. D Disband; unit disbands and disappears from game. Not all units can be disbanded; for instance, most periods will not allow the voluntary destruction of a city. If an occupant is disbanded, then its transport will get any available resources, both those held as sup- plies and any used in making the disbanded unit (pos- sibly not all, depending on the period's "efficiency" parameter). a Cycle through occupants; this can only be used in sur- vey mode, and allows examination of each occupant and its suboccupants. The order of traversal is depth- first, and cycles through all units in the hex repeat- edly. x Mark a unit; used with embarkation, below. Only one unit is ever marked at any one time. e Embark; put the current unit onto a random transport in the same hex. This is useful when you don't want to move transport or unit out just for the purpose of June 22, 1995 - 17 - boarding. If the marked unit is in the same hex, it will be used as the transport. g Give supplies; transfer all types of supplies from the current unit to its transport, if there is one. The default is to try to fill up the transport if possi- ble. If an argument is supplied, it means to transfer exactly that quantity of each resource type. If the current unit is low on some type, then it will transfer half of what was requested. (Repeating the command transfers half again, and so forth.) t Take supplies; transfer all types of supplies to the current unit from its transport, if there is one. The default is to try to fill up the current unit, or to interpret the argument as the quantity to take. If the transport is low, then it will only transfer half of what was requested. O Set standing orders; will ask for type of unit to which standing orders will apply, then goes into a "teach mode"; the next input will saved as an order rather than being applied to some unit. When any unit of the appropriate type enters the unit with the standing order, it will be given those orders and carry them out. There is no way to cancel standing orders at present, but occupants can be set to wake up during entry. G Give unit; give the current unit to the side speci- fied by the argument. If the side is invalid, then the unit is made neutral. Not all unit types can be given away. Commands for side manipulation: c Center; the list of units is sorted so that the one at the current cursor will move first, and others move in concentric circles outward. This is useful for con- centrating on one particular area and reducing the amount of map redrawing. M Message; send a message to another side. The side is specified by giving its number as a prefix to the com- mand; if the number is not the number of a side, then your message will be broadcast to all sides (including yourself). You may type in a message up to the length of the prompt window. Backspacing is available. When a newline is entered, the message is sent immediately to the destination. Specially recognized messages must be typed exactly, with no other words or charac- ters in the message: June 22, 1995 - 18 - war Declare war. Only one side need do this. This involves all allies on both sides immediately. neutral Declare neutrality. Both sides must send this message to each other. alliance If two sides send this message to each other, they become formal allies. The display changes to reflect this, as do things like wakeups, etc. All sides in the game will hear about the alli- ance. briefing Sends the view of all of your units to the other side. Useful for allies, as well as to convince a victim that further resistance is hopeless. Of course, the victim's position might not be so hopeless after all, in which case you've given away all your secrets! Commands for game control. X Resign; resign from the game, (asks for confirmation first). The effect is the same as losing. Q Quit; terminate the game for everybody (asks for con- firmation first). Note that although this can be used even in multi-human games, applying it without prior consent of the other players is definitely anti- social! S Save game; record the game state into a file and exit (asks for confirmation first). The saved game is ASCII and unprotected, so it's possible to "check- point" games and engage in other kinds of cheating. The game exits once it has been saved. To restart, start up the program without any command line argu- ments, and in the directory where the save file is located. If players are specified on the command line, then they override the saved player data. This is one way to switch sides; for instance, saving from "xconq" and restarting with "xconq -r -e 1 $DISPLAY" has the effect of you switching sides with the machine. A Add player; add a new player to the game (not imple- mented yet). o Options; set various options. Each option is a single character. Options at present include: g Graph; toggle between text and bar graph displays about the current unit's supplies, hit points, etc. June 22, 1995 - 19 - d Display mode; cycle between four different color display techniques. The curses interface also has two display modes (one or two terrain chars per hex), but you still have to cycle between four modes. i Invert; invert foreground and background colors everywhere (monochrome only). w Width; set the width of the map display to be the value of the argument. This is measured in hexes. h Height; set the height of the map display to be the value of the argument. This is measured in hexes. n Notices; set the number of notice lines at the top of the screen. r Robot; convert yourself into a machine player. This asks for confirmation, and is not reversi- ble! However, if there are no other human players, ^C is re-enabled, so at least you can terminate the program. m Monochrome; This has the bizarre behavior of converting a color display into its monochrome equivalent. Actually intended for debugging, but pretty flashy if you're bored. Information commands. ? General help; show a sequence of help screens, start- ing with a list of commands, then a display of icons, then any news, then general info about the period, then the characteristics of each unit (as for '=' below). You may page back and forth through the screens. This general help is available in both move and survey modes. Some specialized prompts (such as for unit type) will also recognize '?', but will only supply more details about possible answers to the prompt. / Identify; display a short phrase indicating what is being seen in the hex at the current cursor position. This works in all modes, and is useful for deciphering unusual colors or icons. = List the characteristics of a type of unit. It will prompt for the type, then format all the period- specific details into a semi-readable summary. To get a hardcopy of this, use 'p'. June 22, 1995 - 20 - p Print; dump all the characteristics of all unit types into a file "parms.xconq". This file may be printed, and is very useful for learning about a period. It will include designer's notes about the period which cannot otherwise be obtained. Also print the current view, and a list of the commands. v View current unit; display a flash that should be bright enough to catch the eye and make it easier to see where the current unit is. V Version; display the current version and other useless information. Be sure to include the version number when reporting bugs. ^R, ^LRedraw the screen. Redrawing happens automatically most of the time. Keep in mind that _x_c_o_n_q is a single program, despite opening multiple screens, and attempts to redraw may be ignored for awhile. Additional commands are available for building scenarios, and are described in the customization document. _P_E_R_I_O_D _H_E_L_P The help screens describing unit characteristics include an enormous amount of information. In fact, a period that utilized the full range of capabilities would be too compli- cated to play, even as a computer game. As a result, the help screen are rather compact and cryptic. For any single unit, there are three tables, summarizing the unit's rela- tionships with resource, terrain, and other unit types. The numbers in parentheses are default values that fill in any blank entries. Resources: ToBui Amount of resource needed to build the unit. Prod Amount produced each turn under best conditions. Store Amount that can be carried around. Eats Minimum amount consumed during a turn. ToMov Amount consumed by moving one hex. Hits Amount needed to hit another unit. HitBy Amount needed to be hit by another unit. Terrain: June 22, 1995 - 21 - Slowed Move penalty for entering hex with the given terrain type. Default is negative, which prevents movement entirely. 0 means can move in at maximum speed. Rand% Chance (in hundredths of a percent) to move randomly in the terrain. Hide% Increased difficulty for others to see unit in this terrain. Defn% Increased difficulty for others to hit unit in this terrain. Prod% Productivity of this terrain for resource produc- tion. Attr% Chance (in hundredths of a percent) for attition to occur. Acdn% Chance (in hundredths of a percent) for an accident to occur. Other units: Hit% Chance to hit a unit of that type. Damg Number of hit points of damage done when hit suc- cessful. Cap% Chance to capture unit. Guard 1 if capturing unit converted into garrison. Pro% Percentage of hit that is prevented from hitting the unit type that occupies, or decrease in chance of hit on unit type transporting this unit. Holds Number of units that can be carried. Enter Extra moves consumed by entering the transport type. Leave Extra moves consumed by leaving the transport type. Mob% Transport mobility when carrying unit type. Bridg 1 if can attack unit type across impassable terrain. Build Basic construction time for the unit type. Fix Time to repair one hit point of damage to the unit type. The customization document has additional explanation for some of these (rather obscure) parameters. June 22, 1995 - 22 - _H_I_N_T_S _G_e_n_e_r_a_l_l_y _i_n _w_a_r _t_h_e _b_e_s_t _p_o_l_i_c_y _i_s _t_o _t_a_k_e _a _s_t_a_t_e _i_n_t_a_c_t; _t_o _r_u_i_n _i_t _i_s _i_n_f_e_r_i_o_r _t_o _t_h_i_s. -- _S_U_N _T_Z_U _A_t_t_a_c_k _w_h_e_r_e _h_e _i_s _u_n_p_r_e_p_a_r_e_d; _s_a_l_l_y _o_u_t _w_h_e_n _h_e _d_o_e_s _n_o_t _e_x_p_e_c_t _y_o_u. -- _S_U_N _T_Z_U _T_h_e_r_e _h_a_s _n_e_v_e_r _b_e_e_n _a _p_r_o_t_r_a_c_t_e_d _w_a_r _f_r_o_m _w_h_i_c_h _a _c_o_u_n_t_r_y _h_a_s _b_e_n_e_f_i_t_e_d. -- _S_U_N _T_Z_U The works of Sun Tzu and Clausewitz say nearly all there is to be said on strategy in general. _X_c_o_n_q strategy is fairly close to real strategy. The most important consideration is to conceal your own forces and movements as much as possible. Decoys and feints are worthwhile if they don't draw critcial strength away. Secondly, don't rush to attack with weak forces. Especially over long distances, the defender has the advantage. Wait until you have assembled enough to take and hold a piece of territory, then allow some extra, just in case. Make a plan, and have some contingency plans ready as well. Be ready to take advantage of opportunities. _P_E_R_I_O_D_S _X_c_o_n_q starts with one period compiled into it. It can also read and interpret other periods. Typically the installer will have built in the period called "standard", for which the description is included below. Other periods include Napoleonic times, Ancient Greece, a somewhat silly futuris- tic period, an even sillier "Star Wars" period, whose sole reason for existence is to watch death stars blast cities, a "flattop" period featuring carriers, some simulations of board games, and more. The standard period represents units of about 1945, from infantry to atomic bombs. This is the most familiar, which makes it easier to play, but also more controversial, since historians have many conflicting theories about which kinds of units were most effective. This set has been most influ- enced by other empire games (thus the greater variety of ships), and the numbers have been honed by extensive playing experience at Utah. Infantry. The infantry division is the slowest of units, but it can go almost anywhere. It is also quick to produce. Infantry is the staple of campaigns - a little boring perhaps, but essential to success. June 22, 1995 - 23 - Armor. The armor division is highly mobile and hits hard. Unfortunately, it is limited to operating in open terrain - plains and desert. It also takes longer to produce. Armor can last twice as long in the desert as infantry. Both armor and infantry can assault and capture units; they are the only units that can do so. Fighters. A fighter is a squadron or wing of high- speed armed aircraft. Their fuel supply can be gotten only at units, towns, and bases, so they must continu- ally be taking off and landing. Fighters are not too effective against ground units or ships, but they eat bombers for lunch. Fighters are very good for recon- naisance - important in a game where you can't always see the enemy moving! Bomber groups. Bombers are very powerful, being capa- ble of destroying any unit. Attrition rate in such activities is high, so they're not a shortcut to vic- tory! Bomber performance against other units is less impressive, and of course fighters love to munch on them. Bomber range is greater, but they are slower, taking several turns before they must land. They are also a last-ditch method to escape from a continent if no seaports are available. Destroyers. Destroyers are fast small ships for both exploration and anti-submarine activities. Submarines. The favorite food of submarines is of course merchant shipping and troopships, and they can sink troop transports with one blow. Subs can't be seen by the other side, although their presence might be suspected. Subs are always highly vulnerable to attack by bombers or even fighters. Troop transports. This is how ground units get across the sea. They can defend themselves against ships and aircraft, but are basically vulnerable. They're not very fast either. Aircraft carriers. Compensates for the fighter's lim- ited range by providing a portable airport. Carriers themselves are sitting ducks, particularly with respect to aircraft. Fighter patrols are mandatory. Battleships. The aptly named "Dread Naught" has little to fear from other units of this period. Subs may sink them with enough effort, and a group of bombers and fighters are also deadly, but with eight hit points to start, a battleship can usually survive long enough to escape. Battleships are very effective against units and armies, at least the ones on the coast. June 22, 1995 - 24 - Atomic bombs. The Final Solution; but they are not easy to use. A bomb takes a long time to produce, moves very slowly by itself, is easily destroyed by other units, and reduces the range of bombers that carry it. The plus side is instant destruction for any unit of any size! Bases. To simplify matters, this can serve as a camp, airbase, and port. Bases cannot build units, although they can repair some damage. Towns. Towns are the staple of territory. They pro- duce units at the same rate as cities, but are easier to capture. Cities. Cities are very large, powerful, and well defended. They are basically capital cities, or some- thing in a comparable range. (New York and San Fran- cisco are cities, Salt Lake City and San Antonio are towns.) A city is worth five towns, territory-wise. Current thinking about optimal strategy for this period differs. In general, blitzkrieg works, and can win the game in a hurry. The problem is to muster enough force before striking. One full troop transport is not enough; the inva- sion will melt away like ice cream on a hot sidewalk, unless reinforcements (either air or land) show up quickly. Air cover is very important. While building up an invasion force, airborne assaults using bombers and infantry can pro- vide useful diversions, although it can be wasteful of bombers. Human vs human games on the default map generally last about 100 turns, usually not enough time or units to build atomic bombs or battleships, and not a big enough map to really need carriers (although bases for staging are quite useful.) _C_H_A_N_G_E_S _F_R_O_M _V_E_R_S_I_O_N _1 Aside from the significant changes (hexes, simultaneity, period descriptions), there are a number of smaller changes that will affect experienced players: The command to construct a base is now the same as the general build command ''''PPPP'''' (since bases are units like any other). The random movement command is gone. The disband command is now ''''DDDD'''' instead of ''''dddd''''. There are probably others I have forgotten about. June 22, 1995 - 25 - _A_C_K_N_O_W_L_E_D_G_M_E_N_T_S Special thanks must go to Eric Muehle, now at Martin- Marietta, who has been a tireless source of ideas, advice, and playtesting. Mohammad Pourheidari, Bob Kessler, Kevin Deford, Spencer Thomas, Dan Reading, Mark Bradakis, Grant Weiler, Jed Krohnfeldt, Sandra Loosemore, Jimmy Miklavcic, Tim Moore, and others at Utah have also endured initial playtesting, with the apparently endless bugs and mis- features. Thanks also to Leigh Stoller, who suggested using X, and to Harold Carr, who suggested the postfix language for period descriptions. Since the first release, many many _x_c_o_n_q players around the net have sent in literally hundreds of suggestions, fixes, and improvements. Significant contributors include Jim Anderson at CMU; Jay Scott at Swarthmore, who designed the "future" period; John Tonry at MIT, who supplied a great map derived from JPL data; Kurt Hoyt at SEI, who did an X11 port; Julian Onions at Nottingham; Ravi Subrahmanyam at MCNC; and Joel Rives at Georgia Tech, who is working on a large period. Chris Peterson at MIT and Tim Moore at Utah have been essential to the construction and debugging of the X11 interface to version 5. In addition, A.G. Hirai, Jeff Kelley, John Shovic, Dave Pare, Michael Lounsbery, Josh Siegel, Fred Douglis, Cimarron Taylor, and Rick Ledoux have shared a number of good ideas, although not all of them made it into this version. June 22, 1995